The present invention relates generally to computer communications and, more particularly, to adding NETBIOS protocol support in a known DCE RPC implementation.
A local area network (LAN) provides a distributed computing environment in which users can access distributed resources and process applications on multiple computers. Network communications are carried out using so-called communication protocols. By convention, communication architectures in a local area network are typically characterized as conforming to a seven layer model in the following hierarchy: physical layer, logical link layer, network layer, transport layer, session layer, presentation layer and application layer. The physical layer comprises the actual physical devices and medium used to transmit information. The logical link layer frames data packets and controls physical layer data flow, insuring delivery of data regardless of the actual physical medium. The network layer addresses and routes data packets. It creates and maintains a route in the network between a source node and a destination node. The transport layer creates a transport pipeline between nodes and manages the network layer connections. The session layer typically provides remote procedure call (RPC) support, maintains the integrity of the connection between nodes and controls data exchange. The presentation layer encodes and decodes data and provides transparency between nodes. Finally, the application layer provides the interface to end-user processes and provides standardized services to applications.
The seven layer model has many variations depending on the particular network architecture. Thus, for example, in a network architecture based on the TCP/IP (Transmission Control Protocol/Internet Protocol) interface running IBM RISC System/6000(copyright) computer workstations under the AIX Operating System, there is another layer, called the socket layer, that sits between the session and transport layers. The socket layer creates so-called xe2x80x9csocketsxe2x80x9d which are logical constructs analogous to physical ports. In this architecture, the RPC mechanism is not just supported in the session layer, but also includes functionality of the session layer. A known RPC mechanism useful in distributed computing environments (DCE) includes software code provided by the Open Systems Foundation (OSF).
The OSF DCE RPC mechanism is used conventionally to manage communication between a xe2x80x9cclientxe2x80x9d and a xe2x80x9cserverxe2x80x9d in a distributed computing environment, with the client requesting a service from a server using a remote procedure call (RPC). A xe2x80x9cclientxe2x80x9d refers to a network participant that is requesting a service accessible somewhere within the computing environment. A xe2x80x9cserverxe2x80x9d provides the requested service to a client. With the OSF DCE RPC mechanism, each client process (e.g., a process running on a client machine) has an associated socket created by the socket layer. Each server process likewise is associated with a socket. In response to an RPC, a call directory service returns a data structure, called a xe2x80x9cbinding handle,xe2x80x9d specifying the location of the server process as a network address and the port number where the server process is running. The binding handle is then used by the RPC mechanism to define a communication path between the client process and the server process. The path is defined typically using ip-based (i.e., network layer) protocol sequences of the Internet Network Address Family (AF_INET) to open the sockets.
Local area network managers are becoming more varied, consisting of different LAN technologies, multiple vendors and multiple adapters. There is also a higher performance requirement and a greater need for an increased number of connections to servers and to network management. In the prior art, it is also known to support a number of protocol xe2x80x9cstacksxe2x80x9d on a particular machine to enable support of multiple network protocols. Thus, for example, a machine may support a NETBIOS (NETwork Basic Input/Output System) stack, a TCP/IP (Transmission Control Protocol/Internet Protocol) stack, and other stacks (such as SNA, OSI/CS, and the like). TCP/IP may include an application programming interface layer, called TCPBEUI (which was developed by and available from IBM), for converting NETBIOS programming interface calls to sockets.
As companies move more of their applications to the client/server environment, they desire to access servers from hundreds of computers, some of which use TCP/IP and some of which use NETBIOS. As noted above, current DCE RPC implementations (such as in OS/2) use a sockets API that supports TCP/IP addressing and protocols. Machines running NETBIOS do not have TCP/IP capability and thus are not able to take advantage of DCE RPC services. While use of multiple protocol stacks is a possible solution, system administrators generally do not want to administer a TCP/IP network as well as a NETBIOS network.
It would therefore be desirable to add NETBIOS protocol support to an existing TCP/IP-based DCE RPC mechanism.
It is thus a primary object of the present invention to support the NETBIOS protocol in DCE RPC.
It is a more general object of the invention to enable a NETBIOS-based client to access and use DCE services in a network without requiring that the network be administered under TCP/IP. Preferably, the addressing scheme and protocol sequences are NETBIOS-based, such that there is no need for a TCP/IP protocol stack in the client or use of TCP/IP protocol sequences on the network.
It is another object of the invention to facilitate native NETBIOS protocol support in DCE RPC without requiring changes to RPC application programming interfaces (API""s). In xe2x80x9cnativexe2x80x9d NETBIOS, the particular addressing scheme and protocol sequences are NETBIOS-based.
It is still another object to enable current NETBIOS-based LAN server systems to upgrade without having to add TCP/IP protocol support or to use a TCP/IP protocol stack.
Still another more general object of the invention is to simplify the administration of local area networks by implementing NETBIOS protocol support for DCE RPC without requiring administration of a TCP/IP protocol support and TCP/IP addresses.
Yet another object of the invention is to enable DCE RPC to configure and manage NETBIOS naming conventions.
It is another object of the invention is to eliminate TCP/IP address administration in a DCE implementation using NETBIOS.
Further, it is another more specific object of the invention to implement xe2x80x9cnativexe2x80x9d NETBIOS in DCE with a minimum amount of NETBIOS name administration. NETBIOS hostnames are preferably obtained automatically from a Multiprotocol Transport Networking Service (MPTS) or from the RPC mechanism.
These and other objects of the invention are achieved in a distributed computing environment wherein client machines normally issue remote procedure calls (RPC""s) to server machines over a network using a transport mechanism specified by an application programming interface (API), a first addressing scheme and a first protocol. A preferred method of the invention then begins by configuring a set of application addresses in accordance with a second addressing scheme associated with a second protocol. In response to an RPC issued by a client machine, an application address from the set of application addresses is obtained. Thereafter, the application programming interface of the transport mechanism and the second protocol are used to execute the RPC to a server machine identified by the application address.
In the preferred embodiment, the API of the transport mechanism is sockets and the first protocol is TCP/IP, and the second protocol is NETBIOS. The RPC may be executed using a NETBIOS connection-oriented protocol sequence, or by using a NETBIOS connection-less protocol sequence.
The step of configuring the set of application addresses includes the steps of generating a hostname to represent each server machine in the network that supports NETBIOS applications, and assigning the hostname to a first fixed portion of an application address. The hostname may be automatically generated by a multiprotocol transport service, or it may be generated in some other fashion. In addition to the first fixed portion, the application address has a second variable portion, and the step of configuring the set of application addresses also generates a port number for each NETBIOS application supported on the server machine. The port number may be generated on an as-needed basis by an endpoint mapper to resolve dynamic endpoints.
The foregoing has outlined some of the more pertinent objects of the present invention. These objects should be construed to be merely illustrative of some of the more prominent features and applications of the invention. Many other beneficial results can be attained by applying the disclosed invention in a different manner or modifying the invention as will be described. Accordingly, other objects and a fuller understanding of the invention may be had by referring to the following Detailed Description of the preferred embodiment.